This should be covered in the changelog for entry for the previous PR that added back the missing key.

Addressing the second case described in #13584 (comment):

There is another case I'm still investigating where a user (again with auth configured with a keychain access group and shareAuthStateAcrossDevices == true) is stored on 11.0, 11.1, or 11.2 and missing that key. In this case, such entries will not be read properly when 11.3 adds back the missing key (basically, the same problem you reported but from the upgrade path 11.0/ 11.1/11.2 -> 11.3 (fixed) rather than from 10.x -> 11.0/ 11.1/11.2). I'll leave this issue open until I have a fix for this case also staged in 11.3.

This was tricky enough where I thought it better for the explanation to be embedded next to the code for future us. See diff.

Alternatives considered

• Rather than wrap error handling around the setter, change the code inside the setter. I chose against this as we would have to inspect the query within the setter whereas we have the context we need in the outer scope where we call it. I wanted to keep the setter's implementation unaware of the custom logic needed to solve this bug.

Risks

• The added error handling will delete the iCloud entry from the buggy versions that is corrupting the non-iCloud bucket. Since the corrupt iCloud entry isn't really be synced across devices, it needs to be removed because it's blocking non-iCloud entries from being written. To avoid having to delete this, it would result in trickier keychain migration code that may things more complicated and prone to error.

Test observations

Current behavior on buggy versions:

• In the buggy version, when can an iCloud entry be written?
  • Can it be written when there is already a non-iCloud entry there?
    • No, it cannot because of the conflicting accessibility flag.
  • Can it be written when there is iCloud entry there?
    • Yes, if from buggy version.
    • Maybe, if not from buggy version, because it will depend on if a non-iCloud entry is there (then no) or if the bucket is empty (then yes).
  • Can it be written when there is no entry there?
    • Yes.

Fix #13584